Add count and ordering to json_asserter and non-vnd error reports#25
Add count and ordering to json_asserter and non-vnd error reports#25
Conversation
|
"In addition, the logic for asserting errors in the 400 range did not allow for checking non-vnd errors. This is an issue in the telemetry branch on Transmission, as the response is not vnd and therefore cannot be checked in the normal way, leading to inconsistencies in testing." Isn't the json_asserter code mostly for making assertions about JSON API data? And not just plain json? IDR @mlclay |
|
We have the logic for checking plain JSON successful responses, so it seemed logical to also have an option to check plain JSON failing responses. |
|
The json_asserter was initially intended for JSON API data; however, during initial development, I came across a few situations where testing standard JSON responses was helpful. There is already a basic level of support for plain JSON responses by providing |
mlclay
left a comment
mlclay
left a comment
There was a problem hiding this comment.
I think this is a good change, nice work.
For consistency in the code I have have a recommendation:
Currently the top level success assertions call the intermediate method response_has_data which then calls _test_vnd_json or _test_regular_json based on the value of vnd. This intermediate method is very small, but it does encapsulate the conditional checks to a single location.
However, the error assertion methods have the conditional calls directly to response_has_error or response_has_json_error (also based on vnd). There is no intermediate method to centralize the checking of the conditions for branching to different assertion logic.
I recommend the error response logic to follow the same pattern that exists in the success response methods. This will keep code readability higher as there is consistency between the methods and keeps the code DRYer as the conditional checks are in a single method instead of spread across each top-level error assertion method.
3 participants
This adds two features the json_asserter for 200 checks,
countandcheck_ordering. This allows two things: ensuring the amount of data returned in the list matches the amount expected, and allowing for a precise ordering check on returning data. This allows for better testing of filter/search fields objects, as it can ensure that only the data expected was returned.In addition, the logic for asserting errors in the 400 range did not allow for checking non-vnd errors. This is an issue in the telemetry branch on Transmission, as the response is not
vndand therefore cannot be checked in the normal way, leading to inconsistencies in testing.